Positioning service, location service (LCS) and location-based services (LBS) are becoming more and more important to cellular operators. The introduction of smart phones offers new service possibilities that will require operators to optimize performance, with respect to different positioning requirements for different services, but brings with it new challenges with respect to location services.
In particular, positioning and LCS support for LTE are currently being standardized. Most of the basic signaling support for LCS has been standardized, although work remains. For example, functionality such as LCS QoS (Quality of Service) is not yet complete in the standard. Further, most of the available positioning functionality contemplated in the LTE context has been adopted from UTRAN specifications, even though those specifications are perceived as lacking flexibility and suffering from certain practical problems.
QoS Discrimination in UMTS
LCS QoS Parameters in UMTS
In UMTS, the signalling service between UTRAN or GERAN (in Iu mode) and core network (CN) is provided by the radio network layer signalling protocol called Radio Access Network Application Part (RANAP). At least the following RANAP functions are related to LCS,                Controlling location reporting—the function allows the CN to operate the mode in which the UTRAN reports the UE location using message                    LOCATION REPORTING CONTROL (transmitted from CN to RNC);                        Location reporting—the function used for transferring the actual location information from RNC to the CN using message                    LOCATION REPORT;                        Location related data—the function allows the CN to either retrieve from the RNC deciphering keys (to be forwarded to the UE) for the broadcast assistance data, or request the RNC to deliver dedicated assistance data to the UE by means of messages:                    LOCATION RELATED DATA REQUEST,            LOCATION RELATED DATA RESPONSE, and            LOCATION RELATED DATA FAILURE.                        
It is specified [8] that a Location service request shall include, among the others, such attributes as LCS Client identity, LCS Client Type, and also, if needed, supported GAD shapes, positioning priority, service identity and/or type, and requested QoS information. In UTRAN, this functionality is enabled by RANAP, so that the LCS Client can request a certain QoS of the positioning functionality available in the RNC of UTRAN (the RNC and its corresponding NodeBs are called the Radio Network Subsystem, or RNS; there can be more than one RNS present in an UTRAN). The requested QoS is defined (at least) by the following information elements of the RANAP LOCATION REPORTING CONTROL message, see [1]:                Response time (values: high/low), which is not mapped to time in the standard;        Accuracy code (encoded with 128 values), which is interpreted as the radius in meters of an uncertainty circle when decoded; and        Vertical accuracy code (encoded with 128 values), which is interpreted as the size of the uncertainty interval, but it is unclear in the standard whether it is one- or two-sided.        
Furthermore, the message may also include positioning priority and Client Type (more details in the section that is immediately below).
Client Types in UTRAN
In [8], LCS Client is defined as a software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location information for one or more UEs. LCS Clients subscribe to LCS in order to obtain location information. LCS Clients may or may not interact with human users. The LCS Client is responsible for formatting and presenting data and managing the user interface (dialogue). The LCS Client may reside in the UE or SUPL-Enabled Terminal (SET), but it could also be at the network side (e.g., network maintenance services or BSs positioning themselves).
The Client Type information is very important in practice since it allows for configuring LCS QoS discrimination in a flexible way. Also, there may exist some restrictions for certain LCS client types. For example, in the US, national interim standard TIA/EIA/IS-J-STD-036 restricts the geographic shape for an emergency services LCS client to minimally either an “ellipsoid point” or an “ellipsoid point with uncertainty circle and confidence” as defined in [7]. In UTRAN, the LCS Client type is signaled in the location reporting control message as one of 8 pre-defined values in UTRAN, said values being used to discriminate between different services. The following Client Type values are supported by UTRAN Iu interface, see [1]:
Emergency Services;
Value Added Services;
PLMN Operator Services;
Lawful Intercept Services;
PLMN Operator Broadcast Services;
PLMN Operator Operation and Maintenance Services;
PLMN Operator Anonymous Statistics Services; and
PLMN Operator Target MS Services Support.
It can be noted that there is only one Client Type for commercial LBS (i.e., Value Added Services)—this single type definition is becoming a significant drawback, as the number of commercial location services increases.
Service Types in UTRAN
Service Type is an attribute of specific LBS that may be provided by the LCS client, as defined in [9]. The LCS Client may also provide the service identity, which can then be mapped by the server to a certain Service Type which may also be verified against the LCS profile and the subscription. The following LCS categories and types have been standardized [9]:                Public Safety Services (Emergency Services, Emergency Alert Services);        Location Sensitive Charging;        Tracking Services (Person Tracking, Fleet Management, Asset Management);        Traffic Monitoring (Traffic Congestion Reporting);        Enhanced Call Routing (Roadside Assistance, Routing to Nearest Commercial Enterprise);        Location Based Information Services (Traffic and public transportation information, City Sightseeing, Localized Advertising, Mobile Yellow Pages, Weather, Asset and Service Finding);        Entertainment and Community Services (Gaming, Find Your Friend, Dating, Chatting, Route Finding, Where-am-I); and        Service Provider Specific Services.Confidence in General        
Due to the nature of radio propagation, it is standard to adopt a statistical description of the obtained positions of the terminals. The confidence parameter is then used for description of the statistical error, the confidence being defined as the probability that the terminal is located in the interior of the reported region. The ways the confidence is obtained differ, the reason for this being different statistical models. In A-GPS, the inaccuracy is caused by a combination of pseudo-range measurement errors and geometrical effects. Due to the excess measurements, the law of large numbers together with a linearization provides a motivation for the standard Gaussian position error model. For cell ID and TA positioning the error is rather caused by radio coverage effects. Hence a uniform statistical model for the terminal location is used in these cases.
Selection Logic in UTRAN
The UE Positioning function is controlled by means of operator configurable sets of logic for positioning method selection (the notation “positioning method selection algorithm” will be used below). The positioning method selection algorithm takes a number of inputs, including these items:                The Client Type, received in the LOCATION REPORTING CONTROL message [1];        The QoS parameters (Response Time, Accuracy Code and Vertical Accuracy Code), received in the LOCATION REPORTING CONTROL message [1];        The EnabledPositioningFeatures parameter, with augmented range to cover also RTT Positioning—not relevant for the present invention disclosure; and        The UE Capability, primarily to reveal the A-GPS capability of the UE—not relevant for the present invention disclosure.        
In the first revision of the QoS discriminating positioning feature, three service classes are implemented, with one configurable set of selection logic for each service class. Each service class, except the Emergency Services class which is default, is defined by configured Client Types. There is one dedicated service class for emergency positioning and two service classes for different commercial services.
The logic for each service class allows a first positioning attempt, possibly followed by two re-attempted positioning attempts. The following alternatives are configurable by the operator:
Valid for all service classes:                The typical QoS for each licensed positioning method, including                    Typical response time,            Typical Accuracy Code (Horizontal accuracy expressed as a radius),            Typical Vertical Accuracy Code (Vertical accuracy).                        
Valid for each service class, separately:                A list of Client Types, for which the service class shall be selected.        Note1: A Client Type is only allowed to appear in one service class. Furthermore, no list is needed for the Emergency Services service class, which is the default case.        Note2: Only one Client Type for commercial services is available in UTRAN.        Valid for all positioning attempts.                    Selection of post-check of QoS after each positioning attempt. Note that the QoS is not computed unless a postcheck is configured.                        First Positioning attempt                    An ordered list of selectable positioning methods,            The method with best QoS is selected.                        Second positioning attempt:                    Hard selection of first re-attempted positioning method, from list of selectable positioning methods.            Note: A positioning method that has already been executed is not executed a second time.                        Third positioning attempt:                    Hard selection of second re-attempted positioning method, from list of selectable positioning methods.            Note: A positioning method that has already been executed is not executed a second time.                        
The positioning selection algorithm operates by first checking the Client Type IE that is received in the LOCATION REPORTING CONTROL message. The Client Type will then correspond to the appropriate service class. The positioning method selection algorithm then proceeds by selection of a first positioning method. The selection is QoS-based, and accounts for:                The requested QoS, as received in the LOCATION REPORTING CONTROL message;        The configured (typical) Response Time, Accuracy Code (Horizontal accuracy) and Vertical Accuracy Code (Vertical accuracy), for each of the licensed positioning methods; and        The UE Capability and the enabledPositioningFeatures parameter (which determines if the positioning method is turned on in an RNS)—not relevant for the present invention disclosure.        
The selection algorithm loops over the whole list of configured possible first positioning methods, and selects the method that best meets the QoS criteria. The precedence of the QoS criteria follows 3GPP, i.e., Response Time, Accuracy Code followed by Vertical Accuracy Code. In case two methods are equally good, the first method of the list of configured possible first positioning methods is selected.
After the first positioning method has been selected (selection of no method is a possibility), the selected positioning method is executed.
If configured, a post check of the achieved accuracy is performed, after which it is determined if the UE Positioning function shall proceed with reporting or re-attempted positioning, depending on the outcome of the test. In case of failure of the selected positioning method, the UE Positioning method also proceeds with re-attempted positioning.
In case the UE Positioning function proceeds with re-attempted positioning, the UE Capability and enabledPositioningFeatures are checked, this time for the positioning method which is configured for the second positioning attempt. If the test is successful, the use case corresponding to the UE state and the selected positioning method is executed. At completion, any configured post check is performed to check the achieved accuracy. If the achieved accuracy fulfils the requested accuracy, the result of the second positioning attempt is reported, otherwise a third positioning attempt is performed. A third positioning attempt is also performed in case the second positioning attempt would fail.
The third attempt operates like the second attempt, with the exception that after completion, no post check needs to be performed. The reason is that there is no fourth attempt in case the achieved QoS would not be good enough. For the same reason, the UE Positioning function reports the result of the positioning attempt that best meets the requested QoS, as received in the LOCATION REPORTING CONTROL message.
QoS Evaluation in UTRAN
The QoS evaluation operates by:                Checking if the response time is below the requested response time;        Calculation of areas of the geographical formats that results from each positioning method, and comparison to the area of a circle with a radius given by the requested horizontal accuracy code; and        Calculation/lookup of the size of the vertical inaccuracy that results from each positioning method, and comparison to the requested vertical (scalar) accuracy, as given by the vertical accuracy code received over the RANAP interface.Positioning Architecture and Protocols in LTE        
In LTE, the basic Evolved Packet System (EPS) architecture consists of two nodes in the user plane, a base station and an Evolved Packet Core (EPC) network Gateway (GW). The node that performs control-plane functionality (MME) is separated from the node that performs bearer-plane functionality (i.e., GW). Signaling service between E-UTRAN and EPC is provided over the S1 interface by means of S1 Application Protocol (S1AP) [2]. The S1 interface between eNodeB and MME is called S1-MME and is utilized in control-plane positioning solutions. SLs interface is standardized between MME and eSMLC with LCS-AP protocol operating over the interface. The S1 interface between eNodeB and Serving GW is called S1-U and it is utilized in user-plane positioning solutions.
The following location-related procedures are defined for S1AP in [2]:                Location Reporting Control, which allows the MME to request the eNodeB to report the current UE location, with message                    LOCATION REPORTING CONTROL;                        Location Report, by which the eNodeB provides the UE's current location to the MME by using message                    LOCATION REPORT;                        Location Report Failure Indication, by which eNodeB informs MME that a Location Reporting Control procedure has failed, with message                    LOCATION REPORT FAILURE INDICATION.                        
In [2], LOCATION REPORTING CONTROL message only indicates how the eNodeB shall report to MME and what type of location information (e.g., CSG or TAI). S1AP messages as such do not contain information on the required accuracy, response time, etc. This information is carried by means of LTE Positioning Protocol (LPP) [4], while using S1AP protocol as a transport over the S1-MME interface, so that LPP messages are carried as transparent PDUs over S1-MME.
LPP is a point-to-point protocol used between a location server and a target device in order to position the target device using position-related measurements obtained by one or more reference sources. For LPP messages, a server could, for example, be eSMLC in the control plane or SLP in the user-plane, while a target could be a UE or SET in the control and user planes, respectively. LPP uses RRC as a transport over Uu interface between UE and eSMLC, S1AP over S1 and SLs interface between eNodeB and eSMLC. The following transactions have been specified for LPP,
capability transfer procedure (request/provide messages),
assistance data transfer procedure (request/provide messages),
location information transfer (request/provide messages), etc.
LTE Positioning Protocol Annex (LPPa), see [5], is a protocol between an eNodeB and the eSMLC. The protocol supports the LPPa Location Information Transfer procedures for positioning-related information and LPPa Management procedures not specifically related to LCS.
Depending on the source of the location service request, the procedures flow may differ. That is, the process flow differs depending on whether the LCS request is triggered by the UE, or by the MME or some other EPC LCS entity, or initiated by the eNodeB. In all cases, a location session is invoked by the MME in order to obtain the location of the UE or perform some other location related service such as transferring assistance data to the UE. LPP and LPPa transport are then supported as a part of an LCS session.
In a user-plane solution, SUPL, including the use of LPP over SUPL, takes place as part of the general user-plane protocol stack [6]. SUPL occupies the application layer in the stack, with LPP (or another positioning protocol) transported as another layer above SUPL.
After the LCS session has been established, according to the current standard, the information related to LCS QoS is retrieved during the LPP capability exchange and LPP location information transfer procedures, i.e., after the LCS session has been established.
In the LPP context, capabilities refer to the ability of a target or server to support different position methods defined for LPP, different aspects of a particular position method (e.g., different types of assistance data for A-GNSS) and common features not specific to only one positioning method (e.g., ability to handle multiple LPP transactions). Capability information, among the others, includes methods, velocity types, geographical location types, etc.
Location information request, transmitted optionally, contains at least the following information:                Location information type (estimate preferred, estimate required, measurements required, etc.);        Periodical reporting (amount and reporting interval);        Assistance availability (available assistance information or no server assistance information);        Additional information (may or may not return requested information);        QoS (see details below);        Environment (badArea, notBadArea, mixedArea, etc.);        Location type (a sequence of Boolean indicators for defining location estimates that may be returned by the target with the estimates being one or more of the following locations types: ellipsoidPoint, ellipsoidPointWithUncertaintyCircle, ellipsoidPointWithUncertaintyEllipse, polygon, ellipsoidPointWithAltitude, ellipsoidPointWithAltitudeAndUncertaintyEllipsoid or ellipsoidArc); and        Velocity type (horizontal velocity, horizontal velocity with and without uncertainty, horizontal & vertical velocity with and without uncertainty).        
One can note that location information transfer is a bidirectional procedure, i.e., it can be initiated by request from either side, requesting either for measurements or for estimates, when allowed (e.g., some measurement transmissions are only relevant from a target to a server).
The QoS information part of the location information request comprises the following information:                horizontal accuracy (128 accuracy codes, 100 confidence codes);        vertical coordinate request (Boolean);        vertical accuracy (128 accuracy codes, 100 confidence codes);        response time (a value in range [1, 128] seconds)—the maximum response time as measured between receipt of the Request Location Information and transmission of a Provide Location Information; and        velocity (Boolean).        